Protocol Independent Multicast Last Hop Router Discovery

ABSTRACT

Disclosed is an apparatus comprising a first network node configured to transmit a first message to a second network node, wherein the first message comprises data designating the first network node as a member of a first multicast channel, and wherein the first message comprises data indicating a network address a third network node that is designated as a last hop router (LHR) of the first multicast channel. Also disclosed is a method comprising sending, by a first network node, a protocol independent multicast (PIM) join message, wherein the PIM join message comprises the network address of a PIM channel last hop router (LHR).

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims further priority to U.S. ProvisionalPatent Application No. 61/499,987 filed Jun. 22, 2011 by Lin Han andRenwei Li, and entitled “Method of Protocol Independent Multicast LastHop Router Discovery”, which is incorporated herein by reference as ifreproduced in its entirety.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

Protocol Independent Multicast (PIM) is a family of network routingprotocols that provide one-to-many and many-to-many distribution of dataover Internet Protocol (IP) networks. A network employing PIM maycomprise interconnected network elements (NEs) that function as firsthop routers (FHRs) and last hop routers (LHRs). A FHR may be connectedto a multicast source or a rendezvous point (RP), while an LHR may beconnected to a client device that receives data transmissions from amulticast source or sources. Each LHR may be associated with a multicastgroup address. A multicast source may transmit data to the LHRs bytransmitting data to the multicast group address. Multicast groups maybe dynamic and LHRs may continuously enter and leave the multicast groupby becoming associated and dissociated with the multicast group address,respectively. As the multicast group address may be associated with adynamic group of LHRs, the source and/or FHR may have no efficientmethod to determine the identity of the LHRs associated with themulticast group address at a given time.

SUMMARY

In one embodiment, the disclosure includes an apparatus comprising:afirst network node configured to transmit a first message to a secondnetwork node, wherein the first message comprises data designating thefirst network node as a member of a first multicast channel, and whereinthe first message comprises data indicating a network address a thirdnetwork node that is designated as a LHR of the first multicast channel.

In another embodiment, the disclosure includes an apparatus comprising afirst network node configured to receive a message from a second networknode, wherein the message comprises data designating the second networknode as a member of a multicast channel, and wherein the messagecomprises data indicating a network address of a third network node thatis designated as a LHR of the multicast channel.

In yet another embodiment, the disclosure includes a method comprisingsending, by a first network node, a PIM join message, wherein the PIMjoin message comprises the network address of a PIM channel LHR.

These and other features will be more clearly understood from thefollowing detailed description taken in conjunction with theaccompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in connection with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a schematic diagram of an embodiment of a network with NEscapable of employing PIM.

FIG. 2 is a schematic diagram of an embodiment of a multicast networkwith NEs capable of last hop router discovery.

FIG. 3 is a flowchart of an embodiment a multicast LHR discovery method.

FIG. 4 illustrates an embodiment of an encoding for a PIM join messagecomprising LHR address data.

FIG. 5 is a schematic diagram of an embodiment of a network with NEscapable of employing PIM to transmit quality of service (QoS) data.

FIG. 6 is a schematic diagram of an embodiment of a network with NEscapable of transmitting PIM QoS fail messages.

FIG. 7 illustrates an embodiment of an encoding for a PIM QoS joinmessage.

FIG. 8 illustrates an embodiment of an encoding for a PIM QoS failmessage.

FIG. 9 is a schematic diagram of an embodiment of a network element.

FIG. 10 is a schematic diagram of an embodiment of a general-purposecomputer system.

DETAILED DESCRIPTION

It should be understood at the outset that, although an illustrativeimplementation of one or more embodiments are provided below, thedisclosed systems and/or methods may be implemented using any number oftechniques, whether currently known or in existence. The disclosureshould in no way be limited to the illustrative implementations,drawings, and techniques illustrated below, including the exemplarydesigns and implementations illustrated and described herein, but may bemodified within the scope of the appended claims along with their fullscope of equivalents.

Disclosed herein is an apparatus for and method of performing LHRdiscovery in a multicast system. Specifically, a multicast system, suchas PIM, may comprise a FHR connected to a multicast source, a pluralityof intermediate nodes, and a plurality of LHRs. In order to join amulticast channel, the LHRs may be required to transmit PIM joinmessages toward the FHR through the intermediate nodes. The PIM joinmessages may be sent periodically or triggered by an event. Each PIMjoin message may comprise the unicast network address of the LHR sendingthe message. Each intermediate node may save the network addresses ofall downstream LHRs, merge the PIM join messages, and forward the mergedjoin message toward the FHR. The merged join message may comprise theunicast network addresses of all downstream LHRs in the multicastchannel. The FHR and the intermediate nodes may store the addresses ofthe downstream LHRs in the channel and may forward the addresses to thesource or a network management entity upon request or based on acondition. The multicast network components may use the addresses of theLHRs for locating failures, performing multicast accounting, and/or fortransmitting PIM QoS fail messages.

FIG. 1 is a schematic diagram of an embodiment of a network 100 with NEscapable of employing PIM. The network 100 comprises a source device 131capable of sending data to and receiving data from client devices 111,112, 113, and 114. The source device 131 may be connected to the clientdevices 111-114 through a plurality of NEs 101-106 and a PIM network130. Specifically, the source device 131 may be connected to NE 106,which may be connected to the PIM network 130. NE 105 may connect NEs101-104 to the PIM network 130. Client devices 111-114 may be connectedto NEs 101-104, respectively. It should be understood that NEs 101-106may be part of PIM network 130 and are shown for purposes of clarity.Each connection and/or interface between two NEs may be a PIM enabledconnection/interface. Each connection and/or interface between a NE anda client device may be an IGMP/MLD enabled connection/interface. Theconnection/interfaces between source device 131 and NE 106 may beenabled for IGMP, MLD, PIM, or any other suitable transmission protocol.

The source device 131 may be a machine capable of transmitting data toand receiving data from client devices over an IP network, such as aninternet content provider. Each NE may be a multicast router, or similardevice, configured to receive, transmit, and/or process informationusing PIM channels denoted (S, G) and/or (*, G) where S denotes the IPaddress of a single source device, such as source device 131, G denotesthe IP addresses of all NEs/client devices in a group that haverequested data from the source, and * denotes the IP addresses of allsource devices transmitting to G including any source device 131 and anysource devices that may be located in the PIM network 130. Specifically,a NE may receive a communication from a source, sources, or an upstreamNE, replicate the communication as needed, and transmit thecommunication to downstream NEs or client devices that wish to receivethe communication. Each client device 111-114 may be capable ofrequesting and receiving data from the source device 131. Each clientdevice 111-114 may be a single computer and/or server, a plurality ofcomputers/servers connected by one or more switches and/or routers,mobile device, or any other device or devices commonly employed in hostnetworks, local area networks (LANs), wide area networks (WANs), orsimilar networks. The Client devices 111-114 may enter and/or leavechannel (S,G) and/or (*,G) based on whether a particular client deviceneeds access to the data being transmitted from the source device 131 asdiscussed below.

Requested data may be transmitted from the source device 131 to one ormore of the client devices 111-114 via NEs 101-106 and the PIM network130. A plurality of data transmissions from a source device to a givenclient device may be referred to as a data stream. Data traveling from asource device to a client device may be referred to as moving in adownstream direction or downstream, while data traveling from a clientdevice to the source device may be referred to as moving in a upstreamdirection or upstream. For example, data moving from source device 131to any client device 111-114 travels downstream and data moving from anyclient device 111-114 to source device 131 travels upstream. NE 106 maybe referred to as the FHR as NE 106 is the first router a messageencounters when transmitted from the source device 131. NEs 101-104 maybe referred to as LHRs as each of these NEs may be the last routersmessages encounter when transmitted from the source device 131 to theclient devices 111-114, respectively. The PIM network 130 may compriseany number of NEs connected in any topology. NEs 101-106 and PIM network130 together constitute a PIM network. NEs 101-106 are shown forillustrative purposes.

As discussed above, a source 131 or sources may transmit data to one ormore of the client devices 111-114. Such transmission may beaccomplished by employing various routing methods, schemes, or protocolsbetween the source 131, the FHR 106, the LHRs 101-104, and the clientdevices 111-114. The client devices 111-114 may communicate with theLHRs 101-104 via Internet Group Management Protocol (IGMP) versions onethrough three and Multicast Listener Discovery (MLD) versions one andtwo. Transmissions between the FHR 106 and the LHRs 101-104 may beaccomplished by a multicast scheme such as PIM. Multiple variants of PIMmay be employed including PIM Dense Mode (PIM-DM), PIM Sparse Mode(PIM-SM), PIM Source Specific Mode (PIM-SSM), and PIM Bidirectional Mode(PIM-BIDIR), as set forth in internet engineering task force (IETF)documents request for comments (RFC) 3973, RFC 4601, RFC 3569, and RFC5015, respectively, which are hereby incorporated by reference.

PIM-DM may presume that all downstream nodes wish to receive contenttransmitted by a source 131. In PIM-DM, all data transmitted from thesource 131 may initially be flooded to the entire network 100. A NE mayreceive a prune message from the NE's upstream neighbors and may sendthe prune message to the NE's downstream neighbors. If no response isreceived to indicate that a downstream neighbor node wishes to be amember of channel (*,G) and/or (S, G), the NE and the NE's downstreamneighbors to be removed from the channel. One or more of the NE'sdownstream neighbors may respond with a join message, which may beforwarded to the NE's upstream neighbors to prevent the NE and the NE'sdownstream neighbor from being removed from the channel. If a NE hasbeen previously removed from the channel and a downstream neighborwishes to enter the channel, the downstream neighbor may send a graftmessage to the NE, which may be forwarded to the NE's upstream neighborsand may cause the NE and the NE's downstream neighbors to enter thechannel. A pruned state, e.g. no membership in the channel, may timeoutcausing the NE and the NE's downstream neighbors to reenter the channel.Prune messages may be sent periodically to allow the NE to remain out ofthe channel. Such prune messages may trigger more join messages.

In PIM-SM, a LHR may send a PIM join message toward a NE designated asan RP for the channel (S,G) and/or (*, G), via any intervening NEs. A NEmay be statically or dynamically designated as an RP, depending on theembodiment. All NEs must join through the RP, the RP receives data fromthe source, and transmits the data downstream on behalf of the source.When a join message is sent from a LHR toward the RP, the join messagemay reach the RP or a NE that is already a member of the channel, atwhich point the LHR and any intervening NEs may become members of thechannel. PIM messages from the source, through the RP, may travel backto the LHR through reverse path routing. This process may create an RPmulticast tree, which may be rooted at the RP. Once the RP tree reachesa predetermined size, the RP tree may be converted to a Source Path Tree(SPT), which may allow packets to be routed directly from the source'sFHR to the LHR. Join messages may be periodically refreshed by themembers of the channel, and membership in the channel may timeout if nojoin message is sent from a given NE. PIM-BIDIR may function in asubstantially similar manner to PIM-SM. However, PIM-BIDR may create abidirectional tree between the source and the LHRs, which may passthough the RP. The bidirectional tree may not be converted to a SPT.

In PIM-SSM, a channel may be limited to a single source (S, G). A LHRwishing to join the channel may send a join message upstream to the FHR.Each NE receiving a join message my become part of channel (S, G). Joinmessages may be periodically refreshed by the members of the channel,and membership in the channel may timeout if no join message is receivedby an upstream NE.

Regardless of the version of PIM employed, a NE 101-104 may join orremain in a PIM channel by transmitting join messages upstream to a FHRconnected to a source device 131 or a FHR functioning as an RP. The FHRmay be NE 106 or may be a node in PIM 130 if the source or sources arelocated in PIM 130. For example, source device 131 may comprise twosources 51 and S2. Alternatively, source device 131 may comprise 51 andS2 may be located in the PIM network 130. Client devices 111 and 112 maywish to receive data from 51, while 113 and 114 may wish to receive datafrom S2. The client devices 111-114 may each request to join theirrespective channels by contacting the NEs 101-104 to which each clientdevice is attached using IGMP, MLD, or a similar protocol. NE 101 and102 may each send a join (S1, G1) message to NE 105. NE 103 and 104 mayeach send a join (S2, G2) message to NE 105. NE 105 may send a join (S1,G1) message and a join (S2, G2) message toward the FHR, e.g NE 106,through the PIM network 130 and/or to a FHR in the PIM network 130. NEs101, 102, 105, and 106 may then become or remain members of (S1, G1) andNEs 103, 104, 105, and 106 may become or remain members of (S2, G2),where S1 is the IP address of source 1, S2 is the IP address of source2, G1 is the group of network elements receiving data from S1, and G2 isthe group of network elements receiving data from S2.

Each NE 101-106 may comprise a multicast forwarding information base(MFIB), which may store the NEs PIM group status by making data entriesrelated to all incoming and outgoing PIM join messages. Each NEs MFIBmay also indicate whether the NE should receive data packets from anupstream node and replicate the data packets to be sent to multipledownstream nodes or forward the received data packets withoutreplication.

FIG. 2 is a schematic diagram of an embodiment of a multicast network200 with NEs capable of LHR discovery. The network 200 comprisessubstantially the same components as networks 100 in a differentconfiguration. The network 200 may comprise multicast channel sourcedevices 231-232, NEs 201-210, and client devices 221-226 connected asshown in FIG. 2. All connections in network 200 may be bidirectional.NEs 201-210 may collectively be considered a multicast network, forexample, a PIM network. The solid lines connecting NEs may illustrate afirst multicast tree for multicast channel (S1, G1) and the dashed linesconnecting NEs may indicate a second multicast tree for channel (S2,G2), wherein S1 comprises source 231, S2 comprises source 232, G1comprises NEs 207-209 and 206, and G2 comprises NEs 208-210 and 204. Thesolid and dashed lines may also indicate the client devices 221-223 and226 wish to receive communications from channel (S1, G1) and clientdevices 222-225 wish to receive communications from channel (S2, G2).

As discussed above, the formation of multicast channels may require thatLHRs send join messages to FHRs through intermediate network nodes,where an intermediate network node is a multicast network node that isdownstream from a FHR and upstream from a LHR. A join message related toa multicast channel may be sent from a LHR and may comprise the unicastnetwork address of that LHR. An intermediate node receiving one or morejoin messages from downstream nodes may save the addresses of eachdownstream LHR and the channel or channels the LHR is associated with.If the intermediate node receives multiple join messages, theintermediate node may merge the join messages into a single joinmessage. The intermediate node may then send the merged join messagewith the addresses of all downstream LHRs and channel associationsupstream toward the FHR. In some cases, a LHR may function as anintermediate node to a downstream LHR. The FHR may receive the joinmessages, may store the LHR addresses and channel associations, and maybe aware of all LHRs associated with each channel. The FHR may providethe information to the source, to network management devices, or tousers as needed.

Specifically, NEs 207-209 and 206 may transmit LHR addresses to NE 201(e.g. the FHR) using PIM join messages 251-257, which may be denoted inthe form (S1, G1, NEx) where NEx comprises the unicast addresses of alldownstream LHRs. NE 207 may send join message 251 (S1, G1, NE7) to NE204. NE 208 may send join message 252 (S1, G1, NE8) to NE 204. NE 204may merge join messages 251-252 and transmit join message 256 (S1, G1,NE7-NE8) to NE 202. NE 209 may send join message 253 (S1, G1, NE9) to NE205. NE 206 may send join message 254 (S1, G1, NE6) to NE 205. NE 205may merge join messages 253-254 and transmit join message 255 (S1, G1,NE6, NE9) to NE 202. NE 202 may merge join messaged 255-256 and transmitjoin message 257 (S1, G1, NE6-NE9) to NE 201. NE 201 may receive joinmessage 257 and may store information indicating the LHRs associatedwith channel (S1,G1). Likewise NEs 208-210 and 204 may transmit LHRaddresses to NE 201(e.g. the FHR) using PIM join messages 241-247. NE208 may send join message 241 (S2, G2, NE8) to NE 205. NE 204 may sendjoin message 246 (S2, G2, NE4) to NE 205. NE 205 may merge join messages241 and 246 and may transmit join message 245 (S2, G2, NE4, NE8) to NE203. NE 209 may send join message 242 (S2, G2, NE9) to NE 206. NE 210may send join message 243 (S2, G2, NE10) to NE 206. NE 206 may mergejoin messages 242-243 and transmit join message 244 (S2, G2, NE9-NE10)to NE 203. NE 203 may merge join messages 244-245 and transmit joinmessage 247 (S2, G2, NE4, NE8-NE10) to NE 201. NE 201 may receive joinmessage 247 and may store information indicating the LHRs associatedwith channel (S2,G2). NE 201 may send (S1, G1, NE6-NE9) to source device231 and (S2, G2, NE4, NE8-NE10) to source device 232 as needed for agiven application using any suitable protocol. Source devices 231-232may use LHR address information to determine which client devices areaccessing the multicast content for use in service related to multicastaccounting, billing, and the like. Multicast accounting may comprisedetermining which LHRs/client devices receive multicast channel data,determining the user associated with the LHR or client device, andbilling the user according to multicast channel usage.

A change in network topology may trigger an update of the channelinformation. For example, client 222 may determine to leave channel (S1,G1) and may indicate the determination using suitable protocols (e.g.MLD and/or IGMP). NE 208 may no longer be connected to a client devicethat wishes to receive data from (S1, G1), and may send a multicastprune message (S1, G1, NE8) to NE 204. NE 204 may update a locally savedaddress list and send join message 256 to NE 202 indicating (S1, G1,NE7). Message 256 may be merged with 255 and sent to NE 201 indicating(S1, G1, NE6-NE7, NE9). As another example, the network link between NE205 and NE 202 may fail. NE 202 may detect the failure, scan a locallysaved address list, remove downstream nodes NE6 and NE9 from channel(S1,G1) locally, and send join message 257 indicating (S1, G1, NE7-NE8).NE 202 may also send a prune message requesting NE6 and NE9 be pruned.Each NE receiving the join message 257 or the prune message may alsoscan a locally saved address list, remove downstream nodes NE6 and NE9from channel (S1,G1) locally, and send join/prune messages upstreamuntil the entire channel is aware of the link failure and removal ofnodes NE6 and NE9. Nodes NE6 and NE9 may then join through another linkif able. As a result of this process, a network management device or asystem administrator may use LHR address information available at theFHR and the intermediate nodes for failure testing to determine thelocation of a failed network node, link, or the like. For example, asystem administrator may review the LHR address data from each node in apath traversing a multicast tree from an FHR to an LHR. If the LHRaddress in question appears in a node's address list and does not appearin the address list of an upstream node along the path, a failure mayhave occurred between the two nodes.

Large multicast networks may require that large numbers of LHR addressesbe transmitted toward the FHR. Use of system resources may be reduced byonly transmitting the LHR addresses toward the FHR when a change in thenetwork has occurred, such as a change in topology or change in LHRstatus. Additionally, partial LHR lists may be sent which only compriseaddresses of LHRs with a new multicast channel status or that areaffected by a topology change. Also, certain LHRs may be designated bythe network as important based on the multicast channel being accessedby the LHR, based on the specific characteristics of the LHR, or basedon user defined criteria. The network 200 may be configured to onlytransmit data related to important LHRs to reduce system overhead.

FIG. 3 is a flowchart of an embodiment a multicast LHR discovery method300. In step 301, each LHR in a multicast channel may send a multicastjoin message, such as a PIM join, upstream to the channel FHR viaintermediate nodes. The multicast join message may comprise thetransmitting LHR's unicast network address. In step 302, the upstreamintermediate nodes may receive the join message or messages from thedownstream LHRs. The intermediate nodes may also store the LHR unicastaddresses locally. In step 303, the upstream intermediate nodes maymerge the multicast join messages received in step 302, which may resultin a merged multicast join message comprising the network unicastaddresses of the downstream LHRs. In step 304, the upstream intermediatenodes may send the merged join message toward the FHR. Steps 302-304 maybe repeated by additional upstream nodes until the merged join messagereaches the FHR. In step 305, the FHR receives the join messages fromthe downstream intermediate nodes. The FHR may then store the unicastaddresses for all downstream LHRs.

FIG. 4 illustrates an embodiment of an encoding for a PIM join message400 comprising LHR address data. The join message 400 may comprise aplurality of fields in successive thirty two bit sections, wherein eachsection is numbered from bit position zero to bit position thirty one.The join message 400 may comprise a PIM join header 401, which may beencoded substantially as set forth in IETF documents RFC 5384 and RFC4601, which are hereby incorporated by reference, and may indicate thatthe message 400 is a PIM join message for a channel with a given source.

The join message 400 may comprise a destination header 402. Thedestination header 402 may comprise an F bit and an E bit in bitpositions zero and one as disclosed in RFC 5384. The F bit may be set toa value of one to indicate that the message should be forwarded if a NEreceiving the message is unable to recognize the message. Thedestination header 402 may comprise an Attr_Type field which may be sixbits long, may extend from bit position two to bit position seven, andmay comprise a join attribute value that indicate the destination header402 is to be used for LHR discovery. The Attr_Type field may be set to avalue of three. The destination header 402 may comprise a Number ofDestinations field which may be eight bits long, may extend from bitposition eight to bit position sixteen, and may comprise data indicatingthe number of LHR network addresses stored in the join message 400. Thedestination header 402 may comprise a reserved field which may befourteen bits long, may extend from bit position sixteen to bit positiontwenty nine. The destination header 402 may comprise an N flag and an Fflag, which may be located at bit positions thirty and thirty one,respectively. The N flag and the F flag may be used for QoS provisioningas discussed in FIG. 7.

The join message 400 may further comprise one or more UnicastDestination Address fields 403. Each Unicast Destination Address field403 may be thirty two bits long, may extend from bit position zero tobit position 31, and may comprise data indicating the unicast networkaddress of a downstream LHR of the multicast channel associated with thejoin message 400. The join message 400 may further comprise additionalPIM attributes 404 as set forth in IETF RFC 5384.

FIG. 5 is a schematic diagram of an embodiment of a network 500 with NEscapable of employing PIM to transmit QoS data. The network 500 maycomprise substantially the same components of network 100 and/or 200,but in a different configuration. As shown in FIG. 5, clients 511-514may be connected to NEs 501-504, respectively; NEs 501 and 502 may beconnected to NE 505; NEs 503 and 204 may be connected to NE 506; NE 505may be connected to NE 506 and a first source device 531; and NE 506 mayalso be connected to a second source device 532. NEs 501-504 may beconsidered LHRs and NEs 505 and 506 may be considered FHRs. Thecharacteristics of network 500 described here apply to a network withany number of source devices, NEs, and client devices.

Network 500 may provide for QoS provisioning. When a NE receives adownstream data packet transmitted over a channel, the NE may receivethe packet over an incoming interface, process the packet according tothe MFIB including performing any packet replication, and transmit thepacket and/or replicated packets over an outgoing interface. Thepacket(s) may be placed in various buffers and queued for processing andfor transmission. If the NE receives more packets than the NE is capableof processing and transmitting, the NEs buffers may run out of space,which may prevent new packets from being stored and may lead to packetsbeing dropped. QoS provisioning may allow a NE to allocate buffer spaceor other resources for a particular channel. QoS provisioning may alsoallow a NE to guarantee a particular channel greater queue priority orbandwidth. QoS data may be any data used by the network 500 to performQoS provisioning and may include, without limitation: maximum bandwidth,minimum bandwidth, maximum packet size, maximum latency, and userdefined parameters such as scheduling priority and egress queue depthfor downstream packet forwarding and/or replication. A NE 501-506 mayconsider any QoS data received in performing QoS provisioning. In anembodiment, the NEs 501-506 may consider accumulated latency overmultiple hops and/or perform multicast traffic shaping using a leakybucket algorithm in conjunction with maximum and minimum bandwidthrequests.

Clients 511 and 513 may wish to receive data from channel (S1, G1) andclients 512 and 514 may wish to receive data from channel (S2, G2),where S1 is source device 531 and S2 is source device 532. Clients511-514 may each wish to request QoS provisioning for the datatransmitted to them across an associated channel. Each client 511-514may send QoS data to the NE 501-504, respectively, using IGMP and/orMLD. The LHRs 501-504 may accept the QoS data from clients 511-514,process the QoS data, and transmit the QoS data upstream as part of PIMjoin messages 541-544. Processing the QoS data may involve determiningif local QoS provisioning is possible given current local resources andperforming local QoS provisioning. PIM join messages 541 and 543 mayindicate that clients attached to NEs 501 and 503 wish to join channel(S1, G1) and include the QoS requirements of clients 511 and 513,respectively. Likewise, PIM join messages 542 and 544 may indicate thatclients attached to NEs 502 and 504 wish to join channel (S2, G2) andinclude the QoS requirements of clients 512 and 514, respectively.

NE 505 may receive join messages 541 and 542, and NE 506 may receivejoin messages 543 and 544. As NE 505 and NE 506 may both be attached todownstream clients that wish to join both channels (S1, G1) and (S2,G2), NEs 505 and 506 may both send requests to join both channels. NE505 may send join message 545 to NE 506 as NE 506 is upstream from NE505 with respect to source device 532 for channel (S2, G2). Likewise, NE506 may send join message 546 to NE 505 as NE 505 is upstream from NE506 with respect to source device 531 for channel (S1, G1), join message546 may carry QoS data from NE 503, and join message 545 may carry QoSdata from NE 502. At this point, NE 505 may have received join message546 from NE 503/506 and join message 541 from NE 501. In order toperform QoS provisioning, NE 505 may select the QoS with the moststringent requirements to ensure that QoS provisioning is sufficient forall requesting nodes. For example, if join message 541 contains the moststringent QoS requirements, NE 505 may provision based on the QoSinformation received in 541 and send a join message 547 to source device531 with QoS information based on the QoS information received in 541.Likewise, NE 506 may have received join messages 544 and 545 from NEs502/505 and 504, respectively. If join message 545 comprises the moststringent QoS requirements, NE 506 may send a join message 548 to sourcedevice 532 with QoS information based on the QoS information received in545. This process may result in multicast trees for (S1, G1) and (S2,G2), wherein G1 equals NE 501, 503, and 505-506, wherein G2 equals 502and 504-506, 51 equals source device 531, and S2 equals source device532. This process may also result in QoS provisioning for all clientdevices 511-514. The provisioned QoS resources may later be released ifthe client device(s) requiring QoS wish to leave a channel.

PIM QoS provisioning may be implemented in each version of PIM (e.gPIM-SM, PIM-DM, PIM-SSM, and PIM-BIDIR). As PIM-SSM may comprise asingle source QoS provisioning may be implemented by placing the QoSdata in the PIM join message during multicast tree creation and sendingthe PIM join message across the multicast tree toward the sourceaddress. PIM-SM may have two general embodiments as PIM-SM creates an RPtree and a SPT, which may comprise different root locations. In thefirst embodiment, the RP may be considered the source address as long asthe RP tree is in use. Once RP tree is converted to a SPT, the sourcemay be considered the source address, which may require that the QoSinformation be refreshed for the SPT. In the second embodiment, thenetwork may only perform QoS provisioning once the source tree iscreated. PIM-BIDIR may require the PIM join message be forwarded pastthe RP to the FHR connected to the source. PIM-DM may require that thejoin message with QoS data be forwarded to the FHR in response to aprune message. Also, in PIM-SM, PIM-BIDIR, and PIM-DM, QoS provisioningto multiple FHRs may be required in cases where more than one source isin use, e.g. the scenario denoted by (*, G).

FIG. 6 is a schematic diagram of an embodiment of a network 600 with NEscapable of transmitting PIM QoS fail messages. Network 600 may comprisesubstantially the same components as networks 100, 200, and/or 500 in adifferent configuration and may also comprise a network managementdevice 604. NE 601 may be connected to NE 603 via PIM network 630 and NE602. NEs 601-603 may also be connected to the network management device604 via the PIM network 630. The network management device 604 may beany network node or connected device tasked with managing overallnetwork traffic or reporting network traffic status to networkadministrators.

A QoS reservation may fail at a node because of insufficient resourcesto meet QoS provisioning requirements or because an upstream node is notQoS capable. Network 600 may comprise components capable of handling QoSreservation failures. NE 601 may transmit a join message 641 with QoSdata to NE 602 through the PIM network 630. Join 641 may pass though oneor more NEs in the PIM network 630 and may exit the PIM network 630 asjoin 642, which may include more stringent QoS data from another NEwishing to join the channel. NE 602 may fail to provision QoS resourcesdue to insufficient resources or because NE 602 is aware that upstreamNE 603 is not PIM QoS capable. NE 602 may send a PIM QoS fail message643 back to NE 601 indicating the failure and the reason for thefailure. Alternatively, NE 602 may send a PIM QoS fail message 643 toall downstream LHRs, or all downstream LHRs on a given channel.Additionally or alternatively, the NE 602 may send a PIM QoS failmessage 643 to the network management device 604. If the QoS failure wascaused by an upstream router without PIM QoS capability, NE 603 may senda PIM join message to NE 603 with or without the QoS data. If the QoSfailure was caused by insufficient local resources, depending on theembodiment of network 600, NE 602 may discard the PIM join message 642or send a PIM join message to NE 603 indicating a QoS failure. Uponreceiving a QoS fail message, a NE 601-603 may release any QoS resourcesthat were related to the unsuccessful QoS request.

FIG. 7 illustrates an embodiment of an encoding for a PIM QoS joinmessage 700. The join message 700 may comprise a plurality of fields insuccessive thirty two bit sections, each section being numbered from bitposition zero to bit position thirty one. The join message 700 maycomprise a PIM join header 701, which may be encoded substantially asset forth in IETF documents RFC 5384 and RFC 4601, which are herebyincorporated by reference, and may indicate that the message 700 is aPIM join message.

The join message 700 may comprise a QoS attribute 702, which mayindicate that the join message carries PIM QoS data. The QoS attribute702 may comprise an F bit and an E bit in bit positions zero and one asdisclosed in RFC 5384. The QoS attribute 702 may comprise an Attr_Typefield which may be six bits long, may extend from bit position two tobit position seven, and may comprise data indicating the attribute 702is a QoS attribute. The Attr_Type filed may be set to a value of two.The QoS attribute 702 may comprise a QoS data length field which may beeight bits long, may extend from bit position eight to bit positionsixteen, and may comprise data indicating the length of the QoSattribute 702 and related QoS data 703. The QoS attribute 702 maycomprise a reserved field which may be fourteen bits long, may extendfrom bit position sixteen to bit position twenty nine. The QoS attribute702 may comprise an N flag and an F flag, which may be located at bitpositions thirty and thirty one, respectively. The N flag may be set toindicate a PIM QoS failure message should be sent in case of a PIM QoSfailure. The F flag may be cleared to indicate that the join message 700may not be forwarded to an upstream node if QoS provisioning has failedlocally. The QoS attribute 702 may comprise a Unicast Address of NetworkManagement Server field which may be thirty two bits long, may extendfrom bit position zero to bit position thirty one, and may comprise dataindicating the address of the entity that may be notified in the eventof a PIM QoS failure (e.g. a network management server or a LHR).

The join message 700 may further comprise QoS data 703, which mayindicate the QoS constraints the entity transmitting the join message700 has requested. The QoS data 703 may comprise one or more QoSparameters. Each QoS parameter may comprise a QoS Option Type field, aQoS Option Length field, and a QoS Option Value field. The QoS OptionType field may be eight bits long, may extend from bit position zero tobit position seven, and may comprise data indicating the type of QoSoption that the parameter comprises. The QoS Option Type field mayindicate one of a plurality of QoS options, including minimum bandwidth,maximum bandwidth, maximum packet size, maximum latency, and userdefined. For example, the QoS Option Type field may be set to one toindicate a minimum bandwidth parameter, two to indicate a maximumbandwidth parameter, three to indicate a maximum packet size parameter,four to indicate a maximum latency parameter, and five to indicate auser defined parameter such as queue type or scheduling priority. TheQoS Option Length field may be eight bits long, may extend from bitposition eight to bit position fifteen, and may comprise data indicatingthe length of the QoS parameter. The QoS Option value field may be ofvariable length, may extend from bit position sixteen to bit positionthirty one and may extend to additional thirty two bit segments asneeded. The QoS Option value field may comprise data indicating value ofthe QoS parameter. The join message 700 may further comprise additionalPIM attributes 704 as set forth in IETF RFC 5384.

FIG. 8 illustrates an embodiment of an encoding for a PIM QoS failmessage 800. The fail message 800 may comprise a plurality of fields insuccessive thirty two bit sections, each section being numbered from bitposition zero to bit position thirty one. The fail message 800 maycomprise a PIM Version field 801 which may be four bits long, may extendfrom bit position zero to bit position three, and may indicate theversion of PIM used by the network. The PIM Version field 801 may be setto a value of two. The fail message 800 may comprise a Type field 802which may be four bits long, may extend from bit position four to bitposition seven, and may indicate that the message 800 is a fail message.The Type field 802 may be set to a value of nine. The fail message 800may comprise a U bit 803 and an F bit 804 at positions eight and nine,respectively. The U 803 bit may be set to indicate that the failureoccurred on the uplink and cleared to indicate failure occurred on thedownlink. The F 804 bit may be set to indicate that the message 800 issent in response to a failure and cleared to indicate that the message800 is being sent in response to a previous failure that has now beencorrected. The fail message 800 may comprise an Error Code field 805which may be six bits long, may extend from bit position ten to bitposition fifteen, and may indicate type of QoS failure that hasoccurred. The Error Code field 805 may be set to a value of one toindicate a minimum bandwidth reservation failure, two to indicate amaximum bandwidth reservation failure, three to indicate a maximumpacket size reservation cannot be satisfied, four to indicate requestedlatency cannot be satisfied, and five to indicate a user defined QoSparameter failure. The fail message 800 may comprise a Checksum field806 which may be sixteen bits long, may extend from bit position fifteento bit position thirty one, and may be used for transmission errorchecking. The fail message 800 may comprise a QoS Failed Group Addressfield 807 which may be thirty two bits long and may extend from bitposition zero to bit position thirty one. The fail message 800 maycomprise a QoS Failed Source Address field 808 which may be thirty twobits long and may extend from bit position zero to bit position thirtyone. The QoS Failed Group Address field 807 and the QoS Failed SourceAddress field 808 may be used to indicate the PIM channel and/or (*, G)associated with the failure. The group number of the PIM channel may beencoded in the QoS Failed Group Address field 807, and the source of thePIM channel may be encoded in the QoS Failed Source Address field 808.The fail message 800 may further comprise a QoS Failed PIM Link Addressfield 809 which may be thirty two bits long, may extend from bitposition zero to bit position thirty one, and may indicate the linkaddress of the QoS failure. If the failure occurred because ofinsufficient local resources, the Failed PIM Link Address field 809 mayindicate address of the nodes downstream link. If the failure occurredbecause an upstream node is not PIM QoS capable, the Failed PIM LinkAddress field 809 may indicate the address of the nodes upstream link.

FIG. 9 illustrates an embodiment of a network element 900, which maycomprise a processor or a transceiver as described above, e.g., within anetwork or system. The network element 900 may comprise a plurality ofingress ports 920 and/or receiver units 910 for receiving data, logicunit or processor 930 to process signals and determine where to send thedata to, and a plurality of egress ports 950 and/or transmitter units940 for transmitting data to other systems. The logic unit 930 maycomprise a plurality of ingress buffers and a plurality of egressbuffers for storing received communications prior to processing andprior to transmission to other systems. The logic unit or processor 930may be configured to implement any of the schemes described herein, suchas the multicast LHR discovery method 300, and may be implemented usinghardware, software, or both. For example, the network element 900 may beany NE in a network that implements PIM LHR discovery and/or PIM withQoS as described herein such as illustrative networks network 100-200and 500-600.

The schemes described above may be implemented on any general-purposenetwork component, such as a computer or network component withsufficient processing power, memory resources, and network throughputcapability to handle the necessary workload placed upon it. FIG. 10illustrates a typical, general-purpose network component or computersystem 1000 suitable for implementing one or more embodiments of themethods disclosed herein, such as the multicast LHR discovery method500. The general-purpose network component or computer system 1000includes a processor 1002 (which may be referred to as a centralprocessor unit or CPU) that is in communication with memory devicesincluding secondary storage 1004, read only memory (ROM) 1006, randomaccess memory (RAM) 1008, input/output (I/O) devices 1010, and networkconnectivity devices 1012. The processor 1002 may be implemented as oneor more CPU chips, one or more cores (e.g., a multi-core processor), ormay be part of one or more application specific integrated circuits(ASICs) and/or digital signal processors (DSPs). The processor 1002 maybe configured to implement any of the schemes described herein,including the multicast LHR discovery method 500, which may beimplemented using hardware, software, or both. For example, theprocessor 1002 may include or be coupled to a computer-readable medium,which may be programmed to control the functions of any NE, node,component, or device in networks 100-200 and 500-600.

The secondary storage 1004 is typically comprised of one or more diskdrives or tape drives and is used for non-volatile storage of data andas an over-flow data storage device if RAM 1008 is not large enough tohold all working data. Secondary storage 1004 may be used to storeprograms that are loaded into RAM 1008 when such programs are selectedfor execution. The ROM 1006 is used to store instructions and perhapsdata that are read during program execution. ROM 1006 is a non-volatilememory device that typically has a small memory capacity relative to thelarger memory capacity of secondary storage 1004. The RAM 1008 is usedto store volatile data and perhaps to store instructions. Access to bothROM 1006 and RAM 1008 is typically faster than to secondary storage1004.

At least one embodiment is disclosed and variations, combinations,and/or modifications of the embodiment(s) and/or features of theembodiment(s) made by a person having ordinary skill in the art arewithin the scope of the disclosure. Alternative embodiments that resultfrom combining, integrating, and/or omitting features of theembodiment(s) are also within the scope of the disclosure. Wherenumerical ranges or limitations are expressly stated, such expressranges or limitations should be understood to include iterative rangesor limitations of like magnitude falling within the expressly statedranges or limitations (e.g., from about 1 to about 10 includes, 2, 3, 4,etc.; greater than 0.10 includes 0.11, 0.12, 0.13, etc.). For example,whenever a numerical range with a lower limit, R_(l), and an upperlimit, R_(u), is disclosed, any number falling within the range isspecifically disclosed. In particular, the following numbers within therange are specifically disclosed: R=R₁+k*(R_(u)−R_(l)), wherein k is avariable ranging from 1 percent to 100 percent with a 1 percentincrement, i.e., k is 1 percent, 2 percent, 3 percent, 4 percent, 7percent, . . . , 70 percent, 71 percent, 72 percent, . . . , 97 percent,96 percent, 97 percent, 98 percent, 99 percent, or 100 percent.Moreover, any numerical range defined by two R numbers as defined in theabove is also specifically disclosed. The use of the term “about” means+10% of the subsequent number, unless otherwise stated. Use of the term“optionally” with respect to any element of a claim means that theelement is required, or alternatively, the element is not required, bothalternatives being within the scope of the claim. Use of broader termssuch as comprises, includes, and having should be understood to providesupport for narrower terms such as consisting of, consisting essentiallyof, and comprised substantially of Accordingly, the scope of protectionis not limited by the description set out above but is defined by theclaims that follow, that scope including all equivalents of the subjectmatter of the claims. Each and every claim is incorporated as furtherdisclosure into the specification and the claims are embodiment(s) ofthe present disclosure. The discussion of a reference in the disclosureis not an admission that it is prior art, especially any reference thathas a publication date after the priority date of this application. Thedisclosure of all patents, patent applications, and publications citedin the disclosure are hereby incorporated by reference, to the extentthat they provide exemplary, procedural, or other details supplementaryto the disclosure.

While several embodiments have been provided in the present disclosure,it may be understood that the disclosed systems and methods might beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, modules, techniques, ormethods without departing from the scope of the present disclosure.Other items shown or discussed as coupled or directly coupled orcommunicating with each other may be indirectly coupled or communicatingthrough some interface, device, or intermediate component whetherelectrically, mechanically, or otherwise. Other examples of changes,substitutions, and alterations are ascertainable by one skilled in theart and may be made without departing from the spirit and scopedisclosed herein.

1. An apparatus comprising: a first network node configured to transmita first message to a second network node, wherein the first messagecomprises data designating the first network node as a member of a firstmulticast channel, and wherein the first message comprises dataindicating a network address of a third network node that is designatedas a last hop router (LHR) of the first multicast channel.
 2. Theapparatus of claim 1, wherein the first network node is not the thirdnetwork node.
 3. The apparatus of claim 1, wherein the first multicastchannel is a Protocol Independent Multicast (PIM) channel.
 4. Theapparatus of claim 1, wherein the first network node receives a secondmessage from a downstream member of the first multicast channel prior totransmitting the first message, and wherein the second message comprisesdata indicating the network address of the third network node.
 5. Theapparatus of claim 4, wherein the first network node comprises a table,and wherein the first network node is further configured to store thenetwork address of the third network node and information indicatingthat the third network node is an LHR of the first multicast channel inthe table.
 6. The apparatus of claim 5, wherein the first network nodeis further figured to delete from the table information related to thethird network node if the third network node ceases to be a downstreamnode or ceases to be a member of the first multicast channel.
 7. Theapparatus of claim 6, wherein the first network node determines that thethird network node has ceased to be a downstream node by sensing adownstream link failure.
 8. The apparatus of claim 6, wherein the firstnetwork node determines that the third network has ceased to be a memberof the first multicast channel based on information received in a joinmessage or a prune message.
 9. The apparatus of claim 1, wherein thefirst message further comprises data indicating the network addresses ofa fourth network node, and wherein the fourth network node is designatedas an LHR of a second multicast channel.
 10. The apparatus of claim 9,wherein the first multicast channel and the second multicast channel arethe same channel.
 11. An apparatus comprising: a first network nodeconfigured to receive a message from a second network node, wherein themessage comprises data designating the second network node as a memberof a multicast channel, and wherein the message comprises dataindicating a network address of a third network node that is designatedas a last hop router (LHR) of the multicast channel.
 12. The apparatusof claim 11, wherein the first network node is designated as a first hoprouter (FHR) of the multicast channel, and wherein the multicast channelis implemented using protocol independent multicast (PIM) sourcespecific mode (SSM), PIM sparse mode (SM), PIM dense mode (DM), or PIMbidirectional mode (BIDIR).
 13. The apparatus of claim 11, wherein themessage further comprises a quality of service (QoS) request, andwherein the first network node is configured to transmit a QoS failmessage to the third network node if QoS provisioning associated withthe QoS request could not be satisfied.
 14. The apparatus of claim 11,wherein the first network node is further configured to send the networkaddress of the third network node to a source of the multicast channelfor use in multicast accounting.
 15. The apparatus of claim 11, whereinthe first network node is further configured to send the network addressof the third network node to a source of the multicast channel for usein multicast failure testing.
 16. A method comprising: sending, by afirst network node, a protocol independent multicast (PIM) join message,wherein the PIM join message comprises the network address of a PIMchannel last hop router (LHR).
 17. The method of claim 16, wherein thePIM join message is encoded in a type length value (TLV), and whereinthe TLV comprises: an Attribute Type field comprising data indicatingthat the TLV is a LHR discovery TLV, at least one Unicast DestinationAddress field comprising a network address of a network node designatedas a LHR for a multicast channel, and a Number of Destinations fieldcomprising data indicating the number of Unicast Destination Addressfields encoded in the TLV.
 18. The method of claim 16 further comprisingreceiving a PIM prune message associated with second LHR, wherein theprune message indicates that a client device attached to a second LHRhas left the PIM channel, and wherein the join message is sent inresponse to the prune message.
 19. The method of claim 16, wherein thePIM join message is sent in response to a network link failure, andwherein the link failure occurs in a downstream link connected to thefirst network node.
 20. The method of claim 16, wherein the PIM joinmessage comprises the network address of the LHR if the LHR isdesignated as an important LHR by a user.